Walkie-talkie type services have long proved popular amongst users who wish to communicate brief messages quickly between one another. Walkie-talkie type services are sometimes known as Push-to-talk (PTT) services. Conventionally, such PTT services have been provided by two-way portable radios which utilise a dedicated part of the radio spectrum, but which only allow users to communicate with a small group of pre-selected users who utilise similar terminals and who are within range of the relatively short operating range of the radios. More recently, services have been introduced into the United States which piggy-back on the existing cellular telephone infrastructure. However, these services have been proprietary in nature and have not allowed users to communicate between different operator networks.
In an attempt to broaden the use of PTT services, an industry grouping known as the Open Mobile Alliance (www.openmobilealliance.org) has been established with the aim of standardising suitable protocols which will allow inter-network operability for walkie-talkie services offered over cellular networks. The service established by the various standards is known as Push-to-talk Over cellular (PoC). PoC makes use of the IP Multimedia Subsystem (IMS) to handle the setting up and control of PoC sessions via PoC application servers (acting as SIP ASs). PoC proposes that associated speech data will be transported over a packet switched access technology. In the case of GSM and UMTS, this will be the General Packet Radio Service (GPRS) access technology. In other network architectures, analogous packet switched access technologies will be utilised for transporting talk data. Push to Talk services may also be offered over circuit switched access networks, although this is not the preferred option. The current state of PoC is set out in Release 1.0. The requirements for PoC Release 2 are now being laid out. PoC Release 2 will extend PoC to include multimedia and not just speech.
A PoC AS exists both within the signalling plane and the media plane. It implements a Media Resource Fund on (MRF) comprising a) a Media Resource Function Processor (MRFP) in the media plane node which implements all media-related functions and b) a Media Resource Functon Controller (MRFC) in the signalling plane node that acts as a SIP User Agent to the S-CSCF. Whilst the interface between MRFC and MRFP is not yet standardised, if standardised likely to be based on H.248. It is also likely that the actual (audio) media passing through the MRFP in the case of PoC will use the Real-Time Transport Protocol (RTP) to packetise data or the Message Session Relay Protocol (MSRP) to transport files.
PoC uses the concept of “floor control” to dictate which PoC client involved in a PoC session that may send media at any given time. The MRFC acts as the Media-floor Control Entity for a PoC session. Without permission a PoC Client does not send any type of media, not even media packets indicating silence. Floor control is handled by the allocated PoC application server using the Media Burst Control Protocol (MBCP). MBCP messages are transported across the media layer. Once a PoC session has been established, a PoC client requests the “floor” by sending a MBCP Media Burst Request message to the PoC AS. Assuming that no other PoC client currently has the permission to send media, the PoC AS accepts the request and returns a MBCP Media Burst Granted message to the PoC client.
MBCP defines a “Media Burst Idle” message which is sent out to all participants in a PoC session when no PoC client currently has the permission to send Media. A PoC client receiving this message learns that it can request permission to send media if desired. The PoC AS grants a PoC client the floor for some predefined period, e.g. 10 seconds. After that, the PoC AS revokes the permission to send media and sends out a MBCP Media Burst Idle message to participants. If no participant requests permission to send media, the PoC AS will send out further Media Burst Idle messages at increasing intervals of time, up to some fixed maximum interval.
For a number of reasons a PoC session can “hang”. This is possible, for example, because a PoC client looses radio coverage. In such a case network entities, and in particular SIP proxies within the IMS, may retain state information when this is no longer necessary. Perhaps more importantly, a user may be charged beyond the point when he or she has lost access to a service. It is therefore desirable to provide some kind of keep alive mechanism which allows network entities to learn when a session has hung.
The problems identified above are not restricted to PoC, but are also likely to apply to other IMS enabled services and indeed to non-IMS services which rely upon SIP to establish and control sessions between end-points.
IETF RFC 4028 titled “Session Timers in the Session Initiation Protocol (SIP)” provides one such mechanism which could be applied to PoC sessions. The mechanism requires that a participating SIP client send SIP INVITE or UPDATE messages across the SIP signalling path at regular intervals. In order to avoid overloading the signalling network, it is recommended that the interval at which the keep alive messages are sent is of the order of 30 minutes. However, as IMS sessions in general and PoC sessions in particular are expected to be relatively short lived, application of this mechanism to IMS will still cause state information to be retained within the network long after it is required, and will do little to address the overcharging issue.